Topology partition detection

ABSTRACT

Techniques described herein relate to a method for topology partition detection. Network devices within a network topology often share information to achieve desired network functionality. However, when a network topology becomes partitioned such that not all network devices are directly or indirectly connected to the other network devices, the information sharing may fail. Techniques described herein detect such network topology partitioning by analyzing information that represents the network topology, and the connections therein (e.g., a set of paths).

BACKGROUND

Networks of interconnected devices (e.g., computer networks) ofteninclude any number of network devices. Such network devices may bearranged in a network topology in order to provide connectivity betweendevices within and outside of the network. A network topology may berepresented as a graph of interconnected nodes. Within such networktopologies, routing protocols are often implemented that distributecertain information, at least in part, by sharing the information (e.g.,routing information) between network devices (e.g., in packets) in thenetwork topology. In order for network devices in the network topologyto share such information, the information from each node (e.g., whatneighbor devices is the network device directly connected to, what doesthe network device know about the topology, etc.) may be shared,directly or indirectly, with the other nodes in the network topology.However, conditions may exist in one or more network devices (e.g., oneor more network ports have failed, thereby breaking link(s) betweendevices) that cause network devices to not be operatively connected toeach other. In such scenarios, one or more network devices may no longerbe operatively connected to another device within the scheme beingimplemented for sharing information among the network devices. This maycause the one or more devices to be “partitioned” from the other networkdevices for the purposes of information sharing, which may be referredto as a partition of the graph that represents the network topology.Such a partition may prevent a network from functioning or performing asintended.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 shows an example of a network topology in accordance with one ormore embodiments described herein.

FIG. 2 shows an example of an information sharing topology in accordancewith one or more embodiments described herein.

FIG. 3 shows a flowchart in accordance with one or more embodimentsdescribed herein.

FIG. 4 shows a flowchart in accordance with one or more embodimentsdescribed herein.

FIG. 5 shows a flowchart in accordance with one or more embodimentsdescribed herein.

FIG. 6 shows an example in accordance with one or more embodiments ofdescribed herein.

FIG. 7 shows an example in accordance with one or more embodiments ofdescribed herein.

DETAILED DESCRIPTION

Specific embodiments will now be described with reference to theaccompanying figures.

In general, embodiments described herein relate to techniques fordetecting that a graph representing a network topology, or subsettherein, has become partitioned. In one or more embodiments, a graphrepresenting a network topology may be a graph that includes all networkdevices in the network topology, and has all the network devicesoperatively connected to one another (i.e., they are all operativelyconnected (i.e., directly or indirectly) to each other network device inthe network topology. For example, the graph may represent a subset ofthe actual connections between all the network devices, while stillensuring that the number of connections represented allows the topologygraph to meet certain criteria. Examples of such criteria include, butare not limited to: each network device is at least bi-connected to eachother network device (i.e., there are at least two paths between thenetwork devices); the topology graph has a degree (i.e., number ofconnections from any network device) below a degree threshold; thetopology graph has a diameter (i.e., the longest path between any twonetwork devices) below a diameter threshold; etc. Such a topology graphmay, for example, represent a topology to be used for sharing routinginformation among the network devices so that each network device canmaintain a synchronized copy of a link state database for the networktopology. As such, it may be referred to as an information sharingtopology.

Use of a topology represented by a topology graph that includes only asubset of the actual connections in the network topology may, forexample, reduce the amount of information being redundantly sharedwithin the network topology, which may reduce the load on the networkand the devices therein (e.g., by reducing link state packet flooding),improve network scalability, etc.

However, sharing information only on links represented as connectionsbetween nodes in such a topology graph may lead to scenarios where oneor more network devices in the network topology are not receiving theinformation they require for the network to function as intended.Specifically, events may occur (e.g., link failures, network devicefailures, network devices being removed from service, links being added,network devices being added to the network topology, etc.) that lead toan outcome where the information being shared according to the topologygraph no longer causes all network devices in the network topology toreceive the information needed (e.g., routing information) for thenetwork to operate as intended. In such a scenario, one or more networkdevices may be effectively partitioned from the other devices for thepurposes of receiving the needed information.

In one or more embodiments, embodiments described herein allow for suchpartitions to be efficiently detected, so that corrective actions may betaken to re-join any partitioned network devices to the informationsharing scheme represented, at least in part, by the topology graph.Specifically, in one or more embodiments, whenever a given networkdevice in a network topology determines that a network topology haschanged in some way, the network device initiates a procedure fordetermining if any one or more network devices in the network topologyare partitioned from the other network devices for the purposes ofsharing information, such as routing information.

In one or more embodiments, the procedure for partition detectionincludes obtaining, by a network device in the network topology, arepresentation of the topology graph, which may be represented, forexample, as a set of paths. In one or more embodiments, a path is asubset of the network devices in the network topology, with the firstnetwork device in the path being directly connected to the secondnetwork device, which is connected to the third network device, and soon until the end of that particular path is reached. Accordingly, in oneor more embodiments, a set of paths, when taken together, represent allof the connections between network devices represented by the topologygraph that represents a subset (or all) of the connections in thenetwork topology. In one or more embodiments, the network devicesrepresented in a set of paths may be referred to as nodes.

In one or more embodiments, the network device then makes an assumptionthat all network devices (i.e., nodes) in the network topology arepartitioned from each other. In one or more embodiments, the networkdevice then selects a path from the set of paths, and checks a nodedatabase to see if the first node of the path is already presenttherein. In one or more embodiments, a node database is any datastructure capable of including representations of any kind that havebeen analyzed as part of the partition detection described herein. Inone or more embodiments, if the node is present, then it has alreadybeen added to a partition, which a logical grouping of one or more nodesin the node database based on the node being connected (or not) to othernodes in the node database. Such a logical partition of one or morenodes may be included as additional information in the node database, orstored as information in a separate data structure. In one or moreembodiments, any one or more data structures that include nodeinformation and partition information may be collectively referred to asa partition database. In one or more embodiments, if the node is notpresent in the node database, a new partition is created, and the nodeis added to that partition.

Next, in one or more embodiments, the next node in the path is analyzed,using, for example, a link state database or a list of neighbor nodes(collectively, connectivity information). In one or more embodiments,the analysis determines whether the node is connected to the previouslyanalyzed node.

In one or more embodiments, if the node is connected to the previousnode, then the node database is checked to see if the node is presenttherein. In one or more embodiments, if the node is present, then afirst determination is made as to the greatest union that the node ispresent in, and a second determination is made as to the greatest unionthe previous node is present in.

In one or more embodiments, a union is a logical joining of two or morepartitions. In one or more embodiments, a partition may be added to aunion with another partition based on at least one node in a firstpartition being connected (per the connectivity information) to at leastone other in a second partition. In one or more embodiments, a partitionmay be added to an existing union of two or more partitions to make anew union of all the partitions. In one or more embodiments, unions maybe joined to form new unions with all the nodes in all the partitions sojoined being in the union. In one or more embodiments, the union havingthe most nodes (meaning all the nodes in the union are directly orindirectly connected) may be referred to as the greatest union for anode that has been analyzed and discovered to be connected to theprevious node in the path being analyzed and that was already present inthe node database at the time of the analysis. In one or moreembodiments, a union of partitions may also be referred to as apartition, which includes all the nodes of the partitions that werejoined to create the union. In one or more embodiments, such informationmay also be stored in the partition database.

In one or more embodiments, if the greatest union of the node beinganalyzed is the same as the greatest union that the previous node is in,no action is required, as the nodes are already in the same partition(which may be a union of other partitions, as discussed above). In oneor more embodiments, the two greatest unions are not the same, then anew union is created that includes the two greatest unions (i.e., of thenode being analyzed and the previous node, which are connected to eachother). In one or more embodiments, the new union is a new partitionthat includes all of the nodes in the two unions that were joined.

In one or more embodiments, if the node being analyzed, which was foundto be connected to the previous node, is not present in the nodedatabase, then the node is added to the node database and placed in thepartition with the previous node.

In one or more embodiments, if the analysis of a node determines that itis not connected to the previous node, then the node database isconsulted to determine if the node is already present therein. In one ormore embodiments, if the new node is already present, then no furtheraction is required, as the node is already in a separate partition thanthe previous node. In one or more embodiments, if the node is notpresent, then the node is added to the node database and added to a newpartition.

The above-described process for the node after the first node is thenrepeated for each remaining node in the path, and the above describedprocess including the first node of a path is repeated for all paths inthe set of paths. In one or more embodiments, if, at the end of theanalysis of all the nodes in all the paths in the set of paths leads toa partition database having two or more partitions not joined togetherin a union, then the information sharing topology represented by the setof paths is considered partitioned. In one or more embodiments, if theinformation sharing topology is partitioned, then one or more nodestherein may fail to receive information updates necessary for properoperation of the network topology. In one or more embodiments, eachnetwork device in the network topology performs the above-describedanalysis of partition detection

In one or more embodiments, once an information sharing topology hasbeen determined to be partitioned, corrective action, if possible, maybe taken to join the two or more partitions by adding links to theinformation sharing topology represented by the aforementioned topologygraph. As an example, such corrective action may include each networkdevice in the network topology (all of which performed the same analysisand came to the same conclusion that the information sharing topology ispartitioned) consulting their common link state database and/or localneighbor lists (connectivity information) to determine if they are, infact, directly connected to the partitioned network device even thoughthat connection is not represented in the set of paths that wasanalyzed. In one or more embodiments, if a given network device isconnected to the partitioned network device, the connected networkdevice may add, at least temporarily, the partitioned network device tothe information sharing topology by adding the link between the twodevices, and begin to exchange information with the now-previouslypartitioned network device.

In one or more embodiments, the above-described partition detectionallows an information sharing topology that has become partitioned to berapidly repaired. Such a method of partition detection may also avoidthe need to have a representation of the entire information topologyalready existing in a data structure, which would be required, forexample, to perform a depth first search or breadth first search of theinformation sharing topology. Not requiring an existing data structurerepresenting the entire information sharing topology may conservestorage space on the network devices in the network topology. Such amethod of partition detection may also allow the set of paths to each beanalyzed only once to determine if any the information sharing topologyis partitioned (e.g., as a result of a network topology change).Efficiently analyzing the set of paths only once may reduce the amountof time necessary to detect one or more partitioned network devicesrelative to existing methods of partition detection.

FIG. 1 shows a network topology in accordance with one or moreembodiments described herein. The network topology shown in FIG. 1 isonly one example of a particular network topology. One having ordinaryskill in the art, and the benefit of this Detailed Description, willappreciate that the techniques described herein may apply to any networktopology. Accordingly, embodiments described herein should not beconsidered limited to the network topology shown in FIG. 1.

As shown in FIG. 1, the network topology (100) is a spine-leaf topologythat includes a spine layer (102) and a leaf layer (110). The spinelayer (102) may include any number of spine devices, such as spinedevice A (104), spine device B (106), and spine device N (108). The leaflayer (110) may include any number of leaf devices, such as leaf deviceA (112), leaf device B (114), and leaf device N (116). Each of thesecomponents is described below.

In one or more embodiments, a network topology (100) is an arrangementof various elements of or within a network. In one or more embodiments,a network includes a collection of one or more network devices (e.g.,spine devices (104, 106, 108), leaf devices (112, 114, 116)) thatfacilitate network connectivity for one or more operatively connecteddevices (e.g., computing devices, data storage devices, etc. (notshown)). As used herein, a network may be an entire network or anyportion thereof (e.g., a logical area of network devices within thenetwork). A network may include a datacenter network, a wide areanetwork, a local area network, a wireless network, a cellular phonenetwork, or any other suitable network that facilitates the exchange ofinformation from one part of the network to another. In one or moreembodiments, the network may be coupled with or overlap, at least inpart, with the Internet.

In one or more embodiments, the network topology (100) is a bipartitenetwork topology. In one or more embodiments, a bipartite networktopology is a network topology in which there are at least two sets ofnetwork devices, with connections between devices of one set and devicesof another set, but no connections between devices within a given set.Examples of such network topologies include, but are not limited to, afolded three-stage Clos network topology, and a spine-leaf topology. Inone or more embodiments, such network topologies may be referred to asdense network topologies. In one or more embodiments, a dense networktopology is a network topology (100) in which the network devices arehighly interconnected, with, as an example, each device in a first setof network devices being connected to each device in a second set ofnetwork devices within the network topology. In the exemplary embodimentshown in FIG. 1, the network topology (100) is a spine-leaf topology.Although, FIG. 1 shows an example of a spine-leaf topology, in one ormore embodiments, the network topology is not limited to being aspine-leaf topology (or the particular example shown), or any otherexample of a dense network topology set forth herein, and, as discussedabove, may be any network topology in which an information sharingtopology exists (e.g., for sharing routing information).

In one or more embodiments, when a network topology (100) is arranged asa spine-leaf topology, the network topology (100) includes a leaf layer(110) and a spine layer (102).

In one or more embodiments, a leaf layer (110) is a set of any number ofnetwork devices (e.g., leaf devices (112, 114, 116)) that providenetwork connectivity to any number of attached devices, such ascomputing devices (not shown). In one or more embodiments, a computingdevice is any device or any set of devices capable of electronicallyprocessing instructions and that includes, at least, one or moreprocessors, memory, input and output device(s), and network connectivityvia a leaf layer (110). Examples of computing devices include, but arenot limited to, a server (e.g., a blade-server in a blade-serverchassis, a rack server in a rack, etc.), a virtual machine (VM), adesktop computer, a mobile device (e.g., laptop computer, smart phone,personal digital assistant, tablet computer, and/or any other mobilecomputing device), and/or any other type of computing device with theaforementioned requirements. Other examples of devices for which a leaflayer (110) may provide network connectivity include, but are notlimited to, data storage devices (not shown), other network devices(e.g., wireless routers) (not shown), media devices (e.g., televisions)(not shown), etc.

In one or more embodiments, a spine layer (102) is a set of any numberof network devices (e.g., spine devices (104, 106, 108)) that providenetwork connectivity between network devices of a leaf layer (110), andmay also be operatively connected to other network devices, such as edgerouters (not shown), gateway routers (not shown), network controllers(not shown), etc. In one or more embodiments, each leaf device (112,114, 116) within a leaf layer (110) is operatively connected to eachspine device (104, 106, 108) within a spine layer (102), and each spinedevice (104, 106, 108) within a spine layer is operatively connected toeach leaf device (112, 114, 116) within a leaf layer (110). Suchconnections may be referred to as creating a dense mesh (e.g., a fullmesh) between the leaf layer (110) and the spine layer (102), therebycreating a dense network topology (100).

In one or more embodiments, each leaf device (112, 114, 116) and eachspine device (104, 106, 108) is a network device. In one or moreembodiments, a network device may be a physical device that includesand/or may operatively connected to persistent storage (not shown),memory (e.g., random access memory (RAM)) (not shown), one or moreprocessor(s) (e.g., integrated circuits) (not shown), and two or morephysical network interfaces (which may also be referred to as ports),which may provide connections (i.e., links) to other devices (e.g.,other network devices participating in a routing protocol).

As shown in FIG. 1, examples of such interfaces include ports S:1, S:2,and S:3 on each spine device (104, 106, 108) and ports L:1, L:2, and L:3on each leaf device (112, 114, 116). Although not shown in FIG. 1, leafdevices (112, 114, 116) and/or spine devices (104, 106, 108) may haveany number of additional ports.

In one or more embodiments, the network device also includes any numberof additional components (not shown), such as, for example, networkchips, field programmable gate arrays (FPGAs), application specificintegrated circuits (ASICs), indicator lights, fans, etc.

In one or more embodiments, a network device includes functionality toreceive network traffic data units (e.g., frames, packets, etc.) at anyof the physical network interfaces (i.e., ports) of the network deviceand to process the network traffic data units to determine whether to:(i) drop the network traffic data unit; (ii) process the network trafficdata unit; and/or (iii) transmit the network traffic data unit, based onthe processing, from a physical port of the network device in accordancewith one or more embodiments.

As a non-limiting example, a network chip may be hardware that receivesnetwork traffic data units at an ingress port, and determines out ofwhich egress port on the network device to forward the network trafficdata units such as, for example, media access control (MAC) frames thatmay include Internet Protocol (IP) packets.

In one or more embodiments, a network device (e.g., leaf devices (112,114, 116), spine devices (104, 106, 108)) may include functionality tostore (e.g., in persistent storage, in memory, etc.), any number of datastructures for facilitating operation of at least some aspects of thenetwork device. An example of such a data structure is a link statedatabase (not shown), which stores routing protocol information such asthe state of links (e.g., are connections present) between devices in anetwork topology. Another example of a data structure that may be storedon a network device is a partition database (or set of databases) thatis used to store partition information during a partition detectionanalysis (discussed further in the description of FIGS. 4-6, below).

In one or more embodiments, a link state database is a data structurefor storing link state information received from neighboring networkdevices via the ports of a network device. In one or more embodiments,network devices within a network topology (100) (or a portion thereof(e.g., a logical area within the topology)) share link state informationusing any of a variety of types data units (e.g., packets, frames,messages, advertisements, etc.). Such data units may be sent from onenetwork device to directly connected adjacent network devices, and mayinclude information related to the state of links between the sendingnetwork device and other devices to which the sending network device isoperatively connected, the state of links between other network devicesin a network topology, etc.

When a data unit that includes link state information is received at anetwork device from an adjacent network device, the receiving networkdevice may, in turn, propagate the data unit to its own adjacent networkdevices. Such sharing of link state information between network devicesmay occur within a network topology implementing an interior gatewayprotocol (IGP). Examples of an IGP include, but are not limited to,intermediate system to intermediate system (IS-IS) and open shortestpath first (OSPF), each of which may be referred to as a type of IGPknown as a link-state routing protocol.

In one or more embodiments, when a link-state routing protocol isimplemented within a given network topology (or a portion therein), eachdevice participating in the link-state routing topology receives,directly or indirectly, link state information from other devices in thenetwork topology, or logical area within the network topology. In one ormore embodiments, each network device uses the received information tobuild a map of the connectivity of network devices within the topologyor logical area. Information relating to the map may be stored in thelink state database.

A network device with a complete mapping of the connectivity of networkdevices within a topology or logical area may then use any scheme (e.g.,the Dijkstra algorithm) to determine a best path (e.g., shortest path,path with the least cost, etc.) from itself to other network devices inthe network topology or logical area, and such information may be storedin the link state database and/or used to program other portions of thenetwork device (e.g., a routing information base) with information to beused, for example, when processing a received network traffic data unit.In one or more embodiments, the map of connectivity should be the sameon each network device in a topology or logical area, unless one or morenetwork devices have a change in information related to the state of oneor more links. Accordingly, once a mapping has been determined, linkstate information may be sent from a given network device only when achange to link state information of any link of a network device occurs.

Link-state routing protocols often implement the sending of link stateinformation to adjacent devices in a process often referred to asflooding, which is when the information is sent to each adjacentconnected network device, all of which then send to each of theiradjacent network devices, and so on, until all network devices havereceived the link state information. However, in a dense networktopology (100), such flooding may lead to a large quantity of redundantdata units being transmitted to network devices.

For example, in the spine-leaf network topology (100) shown in FIG. 1,if a link state change is detected on leaf device A (112), informationrelated to the change may be flooded to each of the three spine devices(104, 106, 108). Each of the spine devices may then send the change toleaf device B (114) and leaf device N (116), each of which may send thechange back to the other spine devices, etc. Such redundancy of receiptof link state information when changes occur within a dense networktopology may lead to reduced performance of any given network deviceand/or the network topology as a whole, because each redundant data itemmust be processed in order to determine that it may ultimately bediscarded. As an example, the packet queues (not shown) of a networkdevice leading to a control plane (not shown) of the network device arenecessarily of finite size. Therefore, if the flooding rate exceeds theupdate processing rate for enough time, the control plan may beobligated to drop incoming updates. If such lost updates are ofsignificance, stabilization of the link state database and theconvergence of the network may be delayed.

In one or more embodiments, the possibility of reduced performance ismitigated, at least in part, by only flooding link state changeinformation within a computed information sharing topology, which usesonly a subset of the links connecting network devices within a networktopology (100). Information sharing topologies are discussed further inthe description of FIG. 2, below.

In one or more embodiments, a network device also includes softwareand/or firmware stored in any network device storage (not shown) and/ornetwork device memory (not shown) (i.e., non-transitory computerreadable mediums). Such software may include instructions which, whenexecuted by the one or more processors (not shown) of the networkdevice, cause the one or more processors to perform operations inaccordance with one or more embodiments. The software instructions maybe in the form of computer readable program code to perform embodimentsmay be stored, in whole or in part, temporarily or permanently, on anon-transitory computer readable medium such as a CD, DVD, storagedevice, a diskette, a tape, flash memory, physical memory, or any othercomputer readable storage medium. Specifically, the softwareinstructions may correspond to computer readable program code that whenexecuted by a processor(s), is configured to perform functionalityrelated to embodiments. The functionality of a network device is notlimited to the aforementioned examples.

Examples of a network device include, but are not limited to, a networkswitch, a router, a multilayer switch, a fibre channel device, anInfiniBand® device, etc. A network device is not limited to theaforementioned examples.

While FIG. 1 shows a configuration of components, other configurationsmay be used without departing from the scope of embodiments describedherein. For example, the network topology may be any network topologyother than the spine-leaf topology shown in FIG. 1. As another example,the quantity of network devices in the spine layer may be less (or more)than the quantity of network devices in the leaf layer. As anotherexample, each leaf device and each spine device may have any number ofadditional ports for connecting to any number of other devices, or thatmay not be connected to any other device at a given time. Accordingly,embodiments disclosed herein should not be limited to the configurationof components shown in FIG. 1.

FIG. 2 shows an information sharing topology (e.g., a reducedinformation sharing topology) for sharing information (e.g., routinginformation) within a network topology in accordance with one or moreembodiments described herein. The information sharing topology shown inFIG. 2 is only one example of a particular information sharing topology,and is described in the context of one example of a scheme forinformation between network devices using the information sharingtopology. One having ordinary skill in the art, and the benefit of thisDetailed Description, will appreciate that the techniques describedherein may apply to any network topology and/or any scheme for sharinginformation within a network topology. Accordingly, embodimentsdescribed herein should not be considered limited to the informationsharing topology shown in FIG. 2, or to the information sharing schemedescribed below and in the description of FIG. 3.

As shown in FIG. 2, the information sharing topology (200) includes aleaf layer (212) and a spine layer (202). The spine layer (202) mayinclude a leader (204), spine device B (206), spine device C (208), andspine device D (210). The leaf layer may include leaf device A (214),leaf device B (216), leaf device C (218), and leaf device D (220). Eachof these components is described below.

In one or more embodiments, the leaf layer (212) is substantiallysimilar to the leaf layer (110) shown in FIG. 1 and discussed above.Additionally, in one or more embodiments, the spine layer (202) issubstantially similar to the spine layer (102) shown in FIG. 1 anddiscussed above.

In one or more embodiments, each of the leaf devices (214, 216, 218,220) and each of the spine devices (204, 206, 208, 210) are networkdevices and, as such, are substantially similar, respectively, to theleaf devices (112, 114, 116) and the spine devices (104, 106, 108) shownin FIG. 1 and discussed above. However, for the sake of clarity, all ofthe connections between each leaf device (214, 216, 218, 220) and eachspine device (204, 206, 208, 210) are not shown in FIG. 2. Instead, onlya subset of the connections is shown. The subset may be referred to asan information sharing topology (200).

In one or more embodiments, an information sharing topology (200) is asubset of links within a network topology that includes enough linkssuch that there is at least one path between each network device in thetopology to each other network device in the topology. In one or moreembodiments, information (e.g., link state updates) are only flooded onlinks included in the information sharing topology (200), rather than toall links connected to adjacent network devices, which may, for example,reduce the redundancy of flooding within a network topology implementinga link-state routing protocol. In one or more embodiments, aninformation sharing topology (200) may include more than one pathbetween each device and every other device. For example, as shown inFIG. 2, there are two paths between each network device and every othernetwork device, which may be referred to as a bi-connected informationsharing topology.

However, while the simple bi-connected topology shown in FIG. 2 may beadequate as an information sharing topology (200) for correctness andresiliency, such an information sharing topology may not be optimal forconvergence of link state databases on each of the network deviceswithin the topology, because the diameter (i.e., the longest pathbetween any two network devices in a topology) of the informationsharing topology may be half the number of network devices in thetopology, which may cause an undesired delay in link state updatepropagation. Therefore, in one or more embodiments, the actualinformation sharing topology may have a bound on the diameter, which maybe referred to as a diameter threshold.

Additionally, although FIG. 2 shows an information sharing topology(200) where each network device has two links used as part of theinformation sharing topology, as more redundant paths between nodes areadded to an information sharing topology (200), and when attempting tokeep the diameter of the information sharing topology below a diameterthreshold, specific network devices may end up with more links as partof the information sharing topology than other devices. Having a highnumber of links as part of the information sharing topology may causereduced performance for the network devices with a high number of links.Accordingly, when computing an information sharing topology, in one ormore embodiments, the number of links within the information sharingtopology (i.e., the degree) of any given network device may be bounded,which may be referred to as a degree threshold.

In one or more embodiments, at least one network device in theinformation sharing topology is elected as a leader (204). In one ormore embodiments, a leader (204) is a network device elected using anyscheme for electing a leader within a network topology of logical areaof a network topology. In one or more embodiments, the leader includesfunctionality to compute an information sharing topology, encode thecomputed information sharing topology, and distribute the encodedinformation sharing topology within a network topology or logical areatherein. Election of the leader (204), as well as computation, encoding,and distribution of information sharing topology (200), are discussedfurther in the description of FIG. 3, below.

While FIG. 2 shows a configuration of components, other configurationsmay be used without departing from the scope of embodiments describedherein. For example, as discussed above, there may be more links in thesubset of links that are the information sharing topology, leading tomore paths between network devices (i.e., greater path redundancy). Asanother example, the leader may be any device in the topology, ratherthan a spine device as shown in FIG. 2. As another example, there may bediffering numbers of devices in the spine layer and the leaf layer. Asanother example, there may be differing numbers of links on the variousnetwork devices that are part of the information sharing topology.Accordingly, embodiments disclosed herein should not be limited to theconfiguration of components shown in FIG. 2.

FIG. 3 shows a flowchart describing a method for distributing link stateupdates using an information sharing topology in accordance with one ormore embodiments described herein. The method for creating and using aninformation sharing topology shown in FIG. 3 is only one example of aparticular scheme for sharing information between network devices usingthe information sharing topology. One having ordinary skill in the art,and the benefit of this Detailed Description, will appreciate that thetechniques described herein may apply to any network topology and/or anyscheme for sharing information within a network topology. Accordingly,embodiments described herein should not be considered limited to theinformation sharing topology creation and use shown in FIG. 3.

While the various steps in the flowchart shown in FIG. 3 are presentedand described sequentially, one of ordinary skill in the relevant art,having the benefit of this Detailed Description, will appreciate thatsome or all of the steps may be executed in different orders, that someor all of the steps may be combined or omitted, and/or that some or allof the steps may be executed in parallel.

In Step 300, link state information is distributed by each networkdevice in a network topology in order to build a matching link statedatabase on each network device within the network topology or logicalarea of a network topology. In one or more embodiments, the initial linkstate database is built on each network device using any link-staterouting protocol scheme. For example, both OSPF and IS-IS protocolscause the network devices flood link state information from each networkdevice to each adjacent network device. In one or more embodiments, thelink state database includes information related to a mapping of theconnections between all network devices within the network topology orlogical area of the network topology.

In Step 302, once the link state database, including connectivityinformation, has been built on each network device (i.e., an initialconvergence has occurred), a leader is elected from among the networkdevices. In one or more embodiments, the leader election may occur usingany scheme for electing a single network device from among the networkdevices in a network topology or logical area of a network topology.Such schemes may include any manner of indicating a leader priority,which may be any identifier capable of indicating a relative prioritylevel from among a group of network devices related to which deviceshould be a leader network device. As an example, each network devicemay advertise a leader priority, and the network device with thenumerically highest leader priority may be elected as the leader. In oneor more embodiments, if more than one network device advertises the samehighest leader priority, an election between such devices may be madeusing any other identifying information of the network devices. Forexample, from among the network devices advertising the same highestleader priority, the elected leader may be the network device with thenumerically highest system identifier, internet protocol address, routeridentifier, etc.

In Step 304, the leader computes the information sharing topology. Inone or more embodiments, computing the information sharing topologyincludes computing a set of links from among all the links of thenetwork devices such that each network device has at least two paths toeach other network device. Any higher (or lower) number of paths betweenany two network devices may be used without departing from the scope ofthe embodiments described herein. The determination of the number ofpaths between network devices, and therefore the level of redundancy ofpaths, may include a determination of a desired amount of pathredundancy versus an acceptable level of redundant distribution of linkstate updates. Additionally, in one or more embodiments, computing theinformation sharing topology includes ensuring that the diameter of theinformation sharing topology does not exceed a diameter threshold.Furthermore, in one or more embodiments, computing the informationsharing topology includes ensuring that any given network device withinthe information sharing topology does not exceed a degree threshold.

As an example, a computed information sharing topology may be referredto as a minimal information sharing topology. In one or moreembodiments, a minimal information sharing topology is an informationsharing topology in which the topology is at least bi-connected and eachnode has at least degree two, which may guarantee that the informationsharing topology has no single points of failure. In a spine-leaftopology, a minimal information sharing topology may cause every leafdevice in the information sharing topology to have a degree of two. Asthere are usually more leaf devices than spine devices in a spine-leaftopology, the degree of the spine devices may be higher than that of theleaf devices. In one or more embodiments, the higher load on the spinedevices may be mitigated, at least in part, via an even distribution ofthe load among the individual spine devices. Accordingly, a minimalinformation sharing topology may scale well with a diameter that is keptbelow a diameter threshold.

However, there may be alternate behaviors that can be employed mitigatesuch risk. For example, if a leaf device sees that its single link onthe information sharing topology has failed, the leaf device maycompensate by performing a link state database synchronization checkwith a different spine device (i.e., a spine device outside the knowninformation sharing topology). Similarly, if a leaf device determinesthat its connected spine device within the information sharing topologyhas failed, it may compensate by performing partition detection todetermine if any devices in the network topology have become partitionedfrom the other network devices in the information sharing topology.Partition detection is discussed further in the description of FIGS.4-6, below.

In Step 306, the information sharing topology is encoded. In one or moreembodiments, the information sharing topology is encoded in any mannerof encoding (i.e., representation of data) that is able to represent theconnections between the links of the network devices that are includedin the information sharing topology. For example, if the informationsharing topology was a simple, bi-connected cycle such as that shown inFIG. 2, the information sharing topology may be encoded as a list ofnodes and links in the information sharing topology, and/or as a set ofpaths (discussed above in the description of FIG. 1). As anotherexample, the information sharing topology may be encoded using anadjacency matrix. In one or more embodiments, an adjacency matrix is amatrix in which rows represent one set of devices in a bipartite networkand the columns represent a second set of devices in the bipartitenetwork, with connections between devices that are included in theinformation sharing topology being represented at the appropriateintersection with a 1, and other intersections that are not within theinformation sharing topology being represented as a 0.

In Step 308, the information sharing topology is distributed to allnetwork devices in the network topology or logical area of the networktopology using a current information sharing topology. In one or moreembodiments, the distribution of the information sharing topology isperformed using standard flooding (e.g., flooding as used in IS-IS orOSPF) so that all network devices receive the information sharingtopology. For example, the initial distribution of the informationsharing topology after the information sharing topology is computed bythe leader may be performed using a standard information sharingtopology. In one or more embodiments, after the initial distribution ofthe information sharing topology, subsequent distributions (e.g., afterre-computation of the information sharing topology) may be made usingthe most current information sharing topology prior to there-computation, or the newly re-computed information sharing topology.In one or more embodiments, each network device that receives theinformation sharing topology stores the received information sharingtopology as a part of its link state database. In one or moreembodiments, any change in link state information detected by any givennetwork device is then transmitted from the network device to adjacentnetwork devices according to the information sharing topology, and eachadjacent network device that receives such an update also transmits theupdate via the information sharing topology.

In Step 310, a link state update is received by a network device that isa part of the information sharing topology. In one or more embodiments,the link state update is received from either another network device ona link that is included in the information sharing topology, or on alink that is outside the information sharing topology (e.g., from anetwork device that is not (yet) part of the information sharingtopology).

In Step 312, the received link state update is propagated to adjacentnetwork devices according to the information sharing topology. Forexample, if the information sharing topology dictates that the networkdevice that received the update in Step 310 should transmit the updateto two other network devices, then the link state update is transmittedto only those two devices rather than being flooded to all adjacentnetwork devices. In one or more embodiments, each of the adjacentdevices also transmits the received update according to the informationsharing topology. In one or more embodiments, the process continues totransmit the link state update according to the information sharingtopology until all network devices of the information sharing topology,including the leader, have received the link state update. In one ormore embodiments, although not shown in FIG. 3, if the received updateindicates a change in the network topology, the receiving network deviceperforms a partition detection. Partition detection is discussed furtherin the descriptions of FIGS. 4-6, below

In Step 314, a determination is made, by the leader, whether theinformation sharing topology should be re-computed. In one or moreembodiments, if the leader determines that the link state update wasinitially sent from a network device that is already within theinformation sharing topology, and the update does not include a changethat requires re-computation of the information sharing topology, thenthe information sharing topology is not re-computed, and the process mayoptionally end. Additionally, or alternatively, as shown in FIG. 3, theprocess may optionally return to Step 310 to await any additionalupdates that may be received.

In one or more embodiments, when the leader determines that the linkstate update that was received in Step 310 includes contents thatindicate that an updated information sharing topology is required, thenthe process returns to Step 304, and the information sharing topology isre-computed, re-encoded, and re-distributed.

For example, a link status update may indicate that an informationsharing topology is no longer bi-connected, which causes the leader tore-compute the information sharing topology to satisfy the conditionthat the information sharing topology be at least bi-connected. Othercauses of information sharing topology re-computation found in linkstate updates, such as information related to degree threshold, diameterthreshold, that all network devices (e.g., nodes) of the networktopology are no longer covered, etc., may be used, alone or incombination, without departing from the scope of embodiments describedherein.

In one or more embodiments, if the update causing re-computation of theinformation sharing topology was received from a network device alreadyincluded in the information sharing topology, then the re-computedinformation sharing topology may be sent using the current informationsharing topology prior to the re-computation or the new informationsharing topology. In one or more embodiments, if the update causing theleader to re-compute an information sharing topology was received from anew network device not previously included in the information sharingtopology, then the new network device from which the link state updatewas initially received in Step 310 is included in the updatedinformation sharing topology, and the updated information sharingtopology is distributed throughout the network (e.g., including to thenew network device).

As an example of determining whether to re-compute an informationsharing topology, if a link is added to the topology, the protocol beingused will form a normal adjacency on the link and update the appropriatelink state advertisements for the routers on either end of the link.These link state updates may then be flooded on the information sharingtopology. The leader, upon receiving the updates, may choose to retainthe existing information sharing topology or may choose to modify theinformation sharing topology. If the leader elects to change theinformation sharing topology, it will update the information sharingtopology in the link state database and flood it using the newinformation sharing topology.

FIGS. 4 and 5 show flowcharts describing a method for partitiondetection in accordance with one or more embodiments described herein.While the various steps in the flowchart shown in FIGS. 4 and 5 arepresented and described sequentially, one of ordinary skill in therelevant art, having the benefit of this Detailed Description, willappreciate that some or all of the steps may be executed in differentorders, that some or all of the steps may be combined or omitted, and/orthat some or all of the steps may be executed in parallel.

In Step 400, a network device determines that a network topology thatthe network device is within has changed. In one or more embodiments,detecting a change in a network topology is performed using any suitablescheme for determining that the connections between network devices in anetwork topology have changed in any way. As an example, a networkdevice may receive a link state update from a neighbor device, and,using the link state database of the network device, determine that thelink state update indicates that the network topology has changed. Asanother example, a network device may detect that a neighbor networkdevice is no longer connected (e.g., the neighbor network devicefailed).

In Step 402, the network device obtains a set of paths that represent aninformation sharing topology. In one or more embodiments, as discussedabove in the descriptions of FIG. 1 and FIG. 2, an information sharingtopology is a topology within the network topology that represents howinformation (e.g., link state information) is to be shared among thenetwork devices of the network topology, and may include only a subsetof all links in the network topology. In one or more embodiments, asdiscussed above in the description of FIG. 1, the information sharingtopology may be represented as a set of paths, and may, for example, bestored as part of the link state database of the network device.

In Step 406, the network device selects a path from the set of paths. Inone or more embodiments, any path in the set of paths is suitable to bethe first path or next path selected for analysis. The network devicemay select the path using any scheme for selecting a single instancefrom a group of such instances.

In Step 408, a determination is made whether the first node in the pathselected in Step 406 is present in a node database. As described above,in one or more embodiments, a node database is any data structurecapable of including representations of any kind that have been analyzedas part of the partition detection described herein. In one or moreembodiments, if the node is present, then it has already been added to apartition, which a logical grouping of one or more nodes in the nodedatabase based on the node being connected (or not) to other nodes inthe node database. Such a logical partition of one or more nodes may beincluded as additional information in the node database, and/or storedas information in a separate data structure. In one or more embodiments,any one or more data structures that include node information (i.e., thenode database) and partition information may be collectively referred toas a partition database. In one or more embodiments, if there the firstnode is already present in the node database, then the method proceedsto Step 412. In one or more embodiments, if the node is not present inthe node database, then the method proceeds to Step 410.

In Step 410, in one or more embodiments, if the node is not present inthe node database, the node is added to the node database, a newpartition is created, and the node is added to that partition. In one ormore embodiments, the network device, after determining that the networktopology is changed in Step 400, is programmed to make an assumptionthat each node in the information sharing topology has becomepartitioned from all other nodes in the information sharing topology. Inresponse to the assumption, the network device, after determining thatthe first node of the selected path is not already in a node database,creates a new partition to include the node, and stores that partitionin a database. In one or more embodiments, a partition is a datarepresentation of one or more nodes in an information sharing topology.In one or more embodiments, if there are more than one node in a givenpartition, then the collection of nodes is operatively connected, witheach node having a direct connection to at least one other node in thepartition. In one or more embodiments, after adding the node to the nodedatabase and to a new partition, the method proceeds to Step 412.

In Step 412, a determination is made whether the path has any nextnodes. In one or more embodiments, a path has a next node if there isanother node in the path that the path indicates should be a neighbor ofthe previous node in the path (i.e., the next node is a neighbor of theprevious node). In one or more embodiments, if there is a next node, themethod proceeds to Step 414. In one or more embodiments, if there is nonext node in the path, the method proceeds to Step 430.

In Step 414, a determination is made as to whether the next node of thepath found in Step 412 is connected to the previous node in the path(i.e., it is a neighbor of the previous node). In one or moreembodiments, the determination is made using a connectivity informationfrom a data structure (e.g., a link state database, a neighbor list,etc.) of the network device that includes information relating towhether network devices are neighbors to one another (i.e., are directlyconnected to one another). In one or more embodiments, if the next nodeis a neighbor of the previous node, the method proceeds to Step 416. Inone or more embodiments, if the next node is not a neighbor of theprevious node, the method proceeds to Step 424.

In Step 416, a determination is made whether the next node is in thenext node database. In one or more embodiments, if the next node is inthe node database, the method proceeds to Step 418. In one or moreembodiments, if the next node is not in the next node database, themethod proceeds to Step 424.

In Step 418, the greatest union of the next node, and the greatest unionof the previous node analyzed are computed. As discussed above, in oneor more embodiments, a union is a logical joining of two or morepartitions. In one or more embodiments, a partition may be added to aunion with another partition based on at least one node in a firstpartition being connected (per the connectivity information) to at leastone other in a second partition. In one or more embodiments, a partitionmay be added to an existing union of two or more partitions no make anew union of all the partitions being so joined. In one or moreembodiments, unions may be joined to form new unions with all the nodesin all the partitions so joined being in the new union. In one or moreembodiments, the union having the most nodes (meaning all the nodes inthe union are directly or indirectly connected) may be referred to asthe greatest union for a node that has been analyzed and discovered tobe connected to the previous node in the path being analyzed and thatwas already present in the node database at the time of the analysis. Inone or more embodiments, a union of partitions may also be referred toas a partition, which includes all the nodes of the partitions that werejoined to create the union. In one or more embodiments, such informationmay also be stored in the partition database.

In Step 420, a determination is made whether the greatest union of thenext node and the greatest union of the previous node are the same. Inone or more embodiments, greatest unions are the same if they includethe same set of nodes. In one or more embodiments, if the greatest unionof the node being analyzed is the same as the greatest union that theprevious node is in, no action is required, as the nodes are already inthe same partition (which may be a union of other partitions, asdiscussed above). In one or more embodiments, if the greatest unions arethe same, the method returns to Step 412 to check for additional nodes.In one or more embodiments, if the two greatest unions are not the same,then the method proceeds to Step 422.

In Step 422, a new union is created that includes the two greatestunions (i.e., of the node being analyzed and the previous node, whichare connected to each other). In one or more embodiments, the new unionis a new partition that includes all of the nodes in the two unions thatwere joined. In one or more embodiments, after the new union is created,the next node and the previous node are in the same partition that isthe new union. Accordingly, the method then returns to Step 422 to checkfor additional nodes.

In Step 424, after determining that the next node is not connected tothe previous node in Step 414, a determination is made whether the nextnode is in the node database. In one or more embodiments, if the nextnode is in the node database, then the node is already in a partition,so no further action is necessary with respect to the node, and themethod returns to Step 412 to check for additional nodes. In one or moreembodiments, if the next node is not in the node database, the methodproceeds to Step 426.

In Step 426, in one or more embodiments, if the next node is not presentin the node database, the node is added to the node database, a newpartition is created, and the node is added to that partition. In one ormore embodiments, after adding the node to the node database and to anew partition, the method returns to Step 412 to check for additionalnodes.

In Step 428, after determining that the next node is connected to theprevious node in Step 414, but that the node is not in the node databasein Step 416, the node is added to the node database, and added to thepartition of the previous node. In one or more embodiments, after addingthe node to the node database and to the partition of the previous node,the method returns to Step 412 to check for additional nodes.

In Step 430, once a determination is made that there are no next nodesin a path being analyzed by the network device, a determination is madewhether the set of paths includes any additional paths. In one or moreembodiments, if there are additional paths, the method returns to Step406, another path is selected and analyzed as described above. In one ormore embodiments, if there are no paths, the method ends.

One having ordinary skill in the art, and the benefit of this DetailedDisclosure, will appreciate that although FIG. 4 shows a method to beperformed in response to a single determination that a network topologyhas changed, the method may be repeated each time such a networktopology change is detected. Additionally, one having ordinary skill inthe art, and the benefit of this Detailed Disclosure, will appreciatethat although FIG. 4 shows the method as performed on one networkdevice, the method may be performed on all or any portion thereof ofnetwork devices in a network topology.

Continuing with FIG. 5, in Step 500, a determination is made as towhether there are any nodes that are partitioned from other all othernodes. In one or more embodiments, the determination is made byassessing the partition database to determine if, after performing thepartition detection discussed above in the description of FIG. 4, thereare two or more partitions that exist that have not been joined in aunion. For example, if the partition detection found a partition A, apartition B, a partition C, and a partition D, partitions A and B hadbeen joined in a union to create partition E, and partitions D and C hadbeen joined to create partition F, but partitions E and F were notjoined, then the information sharing topology is partitioned. In one ormore embodiments, if the information sharing topology is partitioned,the method proceeds to Step 502. In one or more embodiments, if thereare no partitioned nodes, then the information sharing topology is stillfunctional (i.e., all nodes should be receiving the information beingshared among the nodes), and the method ends.

In Step 502, a topology correction action set is performed. In one ormore embodiments, a topology correction action set is any one or moreactions that may lead to a repair of the information sharing topology,such that all network devices that should be in the information sharingtopology are receiving the information being shared. An example of suchan action set is for each device in the network topology that performedthe partition detection to consult its database of connectivityinformation (e.g., link state database) to determine if it has aconnection to one or more partitioned devices and, if so, to add, atleast temporarily, a link to the information sharing topology that spansthe partitions, thereby causing the relevant information being shared tobe exchanged with the partitioned one or more nodes.

FIG. 6 shows an example in accordance with one or more embodimentsdescribed herein. The following example is for explanatory purposes onlyand not intended to limit the scope of embodiments described herein.Additionally, while the example shows certain aspects of embodimentsdescribed herein, all possible aspects of such embodiments may not beillustrated in this particular example.

Referring to FIG. 6, consider a scenario in which an area leader of anetwork topology has previously distributed a set of paths (600) thatincludes three paths that collectively represent an information sharingtopology within a network topology, and the set of paths (600) has beenreceived by a network device (not shown) in the network topology (notshown) that includes nodes (not shown) numbered 1-8. In this scenario,although each of nodes 1-8 will perform a partition detection, thisexample will be from the perspective of the network device that is node5 in the information sharing topology represented by the set of paths.

Path A indicates that node 1 should be connected to node 2, and node 2should be connected to node 3. Path B indicates that node 4 should beconnected to node 5, node 5 should be connected to node 6, and node 6should be connected to node 7. Path C indicates that node 2 should beconnected to node 4, node 4 should be connected to node 6, node 6 shouldbe connected to node 8, and node 8 should be connected to node 1.

In this scenario, the following links become broken: the link between 5and 6, the link between 6 and 8, and the link between 8 and 1. Thenetwork device receives at least one link state update from a neighbordevice, and uses the link state database to determine that, indeed, anetwork topology change has occurred. Therefore, in response to thedetermination, the network device begins a partition detection process.

The network device then selects the Path A (1→2→3). The network devicebegins with node 1 (first node in path A), and assign it a partition A(not shown).

Next, the network device consults its link state database, and findsthat it shows that node 2 is connected to node 1, so node 2 is placedinto partition A with node 1.

Next, the network device consults its link state database, and findsthat it shows that node 3 is connected to node 2, so node 3 is placedinto partition A with node 1 and node 2.

Next, the network device determines that there are no more nodes in pathA, so the network device moves on to Path B (4→5→6→7).

Next, the network device determines that node 4 is not in partition A,so the network device creates partition B, and puts node 4 in partitionB.

Next, the network device consults its link state database, and findsthat it shows that node 5 is connected to node 4, so node 5 is placedinto partition B with node 4.

Next, the network device consults its link state database, and findsthat it shows that node 6 is not connected to node 5, and that node 6 isnot in any existing partition, so the network device creates partition C(not shown), and node 6 is placed into partition C.

Next, the network device consults its link state database, and findsthat it shows that node 7 is connected to node 6, so node 7 is placedinto partition C with node 6.

Next, the network device determines that there are no more nodes in pathB, so the network device moves on to Path C (2→4→6→8→1).

Next, the network device determines that node 2 is already in partitionA, so no action is required

Next, the network device consults its link state database, and findsthat it shows that the link between node 4 and node 2 is working (theyare neighbors in the link state database). The network device thenconsults the partition database to discover that node 2 is in partitionA, and node 4 is in partition B, so we create partition D (not shown) tocreate a union between partition A and partition B that includes nodes1-5.

Next, the network device consults its link state database, and findsthat it shows that the link between node 6 and node 4 is working (theyare neighbors in the link state database). The network device thenconsults the partition database to discover that node 4 is in partitionD, and node 6 is in partition C, so we create partition E to create aunion between partition D and partition C that includes nodes 1-7.

Next, the network device consults its link state database, and findsthat it shows that node 8 is not connected to node 6, and that node 8 isnot in any existing partition, so the network device creates partition F(not shown), and node 8 is placed into partition F.

Next, the network device consults its link state database, and findsthat it shows that node 1 is not connected to node 8, but that node 1 isalready in partition A, so no action is taken.

A graphic representation of the results of the above-described partitiondetection is shown in FIG. 7 as partitioned information sharing topology(700)

Based on the above-described partition detection, the network devicethat is node 5 has determined that node 8 is partitioned from the otherdevices in the information sharing topology. Accordingly, node 5consults its link state database and determines that although it is notshown as connected to partitioned node in the set of paths, it is, infact, physically a neighbor of node 8. Therefore, node 5 adds the linkto node 8 to the information sharing topology and begins exchanging linkstate updates with node 8, thereby repairing the partitioning of theinformation sharing topology.

Example Embodiments

In general, in one aspect, embodiments described herein relate to amethod for topology partition detection. In one or more embodiments, themethod includes making a first determination, by a network device of anetwork, that a topology of the network has changed; obtaining, based onthe first determination, a set of paths from a current topology for thenetwork; assigning a first node of a first path of the set of paths to afirst partition; making a second determination, using the first path,that a second node should be connected to the first node; making a thirddetermination, using connectivity information of the network device,that the first node and the second node are neighbors; and assigning,based on the third determination, the second node to the firstpartition.

In general, in one aspect, embodiments described herein relate to amethod for topology partition detection. In one or more embodiments, themethod includes making a first determination, by a network device in anetwork, that a topology of the network has changed; obtaining, by thenetwork device and based on the first determination, a set of paths froma current topology for the network; and performing, by the networkdevice, a partition detection action set using the set of paths and alink state database of the network device, wherein the partitiondetection action set determines whether the current topology ispartitioned.

In general, in one aspect, embodiments described herein relate to anon-transitory computer readable medium including instructions that,when executed by a processor, perform a method for topology partitiondetection. In one or more embodiments, the method includes making afirst determination, by a network device in a network, that a topologyof the network has changed; obtaining, by the network device and basedon the first determination, a set of paths from a current topology forthe network; and performing, by the network device, a partitiondetection action set using the set of paths and a link state database ofthe network device, wherein the partition detection action setdetermines whether the current topology is partitioned.

In the above description, numerous details are set forth as examples ofembodiments described herein. It will be understood by those skilled inthe art, and having the benefit of this Detailed Description, that oneor more embodiments of embodiments described herein may be practicedwithout these specific details and that numerous variations ormodifications may be possible without departing from the scope of theembodiments described herein. Certain details known to those of ordinaryskill in the art may be omitted to avoid obscuring the description.

In the above description of the figures, any component described withregard to a figure, in various embodiments described herein, may beequivalent to one or more like-named components described with regard toany other figure. For brevity, descriptions of these components will notbe repeated with regard to each figure. Thus, each and every embodimentof the components of each figure is incorporated by reference andassumed to be optionally present within every other figure having one ormore like-named components. Additionally, in accordance with variousembodiments described herein, any description of the components of afigure is to be interpreted as an optional embodiment, which may beimplemented in addition to, in conjunction with, or in place of theembodiments described with regard to a corresponding like-namedcomponent in any other figure.

Throughout the application, ordinal numbers (e.g., first, second, third,etc.) may be used as an adjective for an element (i.e., any noun in theapplication). The use of ordinal numbers is not to imply or create anyparticular ordering of the elements nor to limit any element to beingonly a single element unless expressly disclosed, such as by the use ofthe terms “before”, “after”, “single”, and other such terminology.Rather, the use of ordinal numbers is to distinguish between theelements. By way of an example, a first element is distinct from asecond element, and the first element may encompass more than oneelement and succeed (or precede) the second element in an ordering ofelements.

As used herein, the phrase operatively connected, or operativeconnection, means that there exists between elements/components/devicesa direct or indirect connection that allows the elements to interactwith one another in some way. For example, the phrase ‘operativelyconnected’ may refer to any direct (e.g., wired directly between twodevices or components) or indirect (e.g., wired and/or wirelessconnections between any number of devices or components connecting theoperatively connected devices) connection. Thus, any path through whichinformation may travel may be considered an operative connection.

While a limited number of embodiments have been described herein, thoseskilled in the art, having benefit of this disclosure, will appreciatethat other embodiments can be devised which do not depart from the scopeof the embodiments described herein. Accordingly, the scope ofembodiments described herein should be limited only by the attachedclaims.

What is claimed is:
 1. A method for topology partition detection, themethod comprising: making a first determination, by a network device ofa network, that a topology of the network has changed; obtaining, basedon the first determination, a set of paths from a current topology forthe network; assigning a first node of a first path of the set of pathsto a first partition; making a second determination, using the firstpath, that a second node should be connected to the first node; making athird determination, using connectivity information of the networkdevice, that the first node and the second node are neighbors;assigning, based on the third determination, the second node to thefirst partition; making a fourth determination, using the first path,that a third node in the first path should be connected to the secondnode; making a fifth determination, using the connectivity information,that the second node and the third node are not neighbors; andassigning, based on the fifth determination, the third node to a secondpartition; making a sixth determination, using a second path of the setof paths and the connectivity information that the second node and thethird node are neighbors and should be connected; merging, based on thesixth determination, the first partition and the second partition into athird partition comprising the first node, the second node, and thethird node; making a seventh determination that a fourth node of a thirdpath of the set of paths is not in the first partition; assigning, basedon the seventh determination, the fourth node to a fourth partition;making an eighth determination that the third path does not include anynodes that should be connected to the first node, the second node, orthe third node; making a ninth determination, based on the eighthdetermination, that the current topology is partitioned into the thirdpartition and the fourth partition; and performing, based on the ninthdetermination, a topology repair action set.
 2. The method of claim 1,wherein performing the topology repair action set comprises: performingan analysis on the connectivity information to determine that the fourthnode and the first node are neighbors; and repairing, based on theanalysis, the current topology by updating the current topology to add alink between the fourth node and the first node, wherein adding the linkallows for transmitting link state information between the first nodeand the fourth node.
 3. A method for topology partition detection, themethod comprising: making a first determination, by a network device ina network, that a topology of the network has changed; obtaining, by thenetwork device and based on the first determination, a set of paths froma current topology for the network; and performing, by the networkdevice, a partition detection action set using the set of paths and alink state database of the network device, to detect that the currenttopology is partitioned into a first partition and a second partition,performing, in response to detecting that the current topology ispartitioned, a topology repair action set, wherein performing thetopology repair action set comprises: making a second determination,using the set of paths, that a first node in the first partition and asecond node in the second partition are not connected in the currenttopology; performing an analysis, using the link state database, todetermine that the first node is a neighbor of the second node; andrepairing, based on the analysis, the current topology by transmittinglink state information between the first node and the second node. 4.The method of claim 3, wherein performing the partition detection actionset comprises: assigning the first node of a first path of the set ofpaths to the first partition; making a third determination, using thefirst path, that the second node should be connected to the first node;making a fourth determination, using the link state database, that thefirst node is the neighbor of the second node; and assigning, based onthe third determination and the fourth determination, the second node tothe first partition with the first node.
 5. The method of claim 3further comprising: performing, by the network device in response to thefirst determination, an analysis to determine routes to each of aplurality of other network devices in the network.
 6. The method ofclaim 3, wherein making the first determination comprises receiving alink state update from a second device of the network.
 7. The method ofclaim 3, wherein making the first determination comprises receiving anupdated topology.
 8. The method of claim 3, wherein the link statedatabase comprises link state information indicating whether nodes ofthe current topology are neighbors.
 9. A non-transitory computerreadable medium comprising instructions that, when executed by aprocessor, perform a method for topology partition detection, the methodcomprising: making a first determination, by a network device in anetwork, that a topology of the network has changed; obtaining, by thenetwork device and based on the first determination, a set of paths froma current topology for the network; performing, by the network device, apartition detection action set using the set of paths and a link statedatabase of the network device to detect that the current topology ispartitioned into a first partition and a second partition; andperforming, in response to detecting that the current topology ispartitioned, a topology repair action set, wherein performing thetopology repair action set comprises: making a second determination,using the set of paths, that a first node in the first partition and asecond node in the second partition are not connected in the currenttopology; performing an analysis, using the link state database, todetermine that the first node is a neighbor of the second node; andrepairing, based on the analysis, the current topology by transmittinglink state information between the first node and the second node. 10.The non-transitory computer readable medium of claim 9, whereinperforming the partition detection action set comprises: assigning thefirst node of a first path of the set of paths to the first partition;making a third determination, using the first path, that the second nodeshould be connected to the first node; making a fourth determination,using the link state database, that the first node is the neighbor ofthe second node; and assigning, based on the third determination and thefourth determination, the second node to the first partition with thefirst node.
 11. The non-transitory computer readable medium of claim 9,wherein the method further comprises: performing, by the network devicein response to the first determination, an analysis to determine routesto each of a plurality of other network devices in the network.
 12. Thenon-transitory computer readable medium of claim 9, wherein making thefirst determination comprises receiving a link state update from asecond device of the network.
 13. The non-transitory computer readablemedium of claim 9, wherein making the first determination comprisesreceiving an updated topology.
 14. The non-transitory computer readablemedium of claim 9, wherein the link state database comprises link stateinformation indicating whether nodes of the current topology areneighbors.